Automated Checks (advisory, non-blocking)

✅ All checks passed.

⚠️ Partial review: The diff exceeded size limits. Feedback below focuses on early files and high-level risks only.

Standards Compliance

This PR is directly in the repo’s highest-risk area: no-leak boundary, citation/mode semantics, eval coverage, and demo artifact migration. From the visible diff, I don’t see a clear standards violation, and one issue from my prior review appears addressed by the migration/hash-invariant testing around the committed demo artifacts.

Because the only visible code change here is the large demo/corpus/index.json churn to schema version:3, the main standards checks for the reviewer are structural ones in the unseen code:

• [UNVERIFIED] Stale index handling should fail loudly
  The standards require malformed/stale index data to throw clearly, not degrade silently. With the schema bump described in the PR, please verify the index loader rejects v2 local indexes with an explicit version error rather than accepting them partially.

• [UNVERIFIED] Public-traveling fields should stay on the new public-safe path only
  Given the A1 change, the reviewer should confirm the new label/locator fields are the only metadata that can travel into prompts/citations, and that private note title cannot still leak through a fallback path. That’s the repo’s “boundary stays structural” requirement, not a convention check.

• [UNVERIFIED] Related-material finalization should overwrite model prose after grounding
  The A2 change is standards-critical: related-material mode must “point, never assert content.” Please verify finalizeAnswer always discards model-generated prose for that mode and renders only from public-safe hint fields after repair/grounding.

Summary

This PR appears to do three coordinated things: add adversarial gold cases for leak/mode failures, structurally template related-material answers from public-safe hint metadata, and migrate the index schema so private note titles no longer double as traveling labels. Most of the visible diff is committed demo/ artifact churn from the schema migration rather than business-logic changes.

Reviewer: most of the risk is in the unseen index-loading, public-safe boundary enforcement, and answer-finalization paths; the giant JSON update is mostly a consequence.

What to pay attention to

• Schema v3 loader/migration behavior
  This deserves attention because the PR intentionally makes existing local indexes stale. The important question is whether runtime failure is explicit and immediate.

• PublicSafe construction and escape hatches
  The author says this is structural. The reviewer should confirm normal app code cannot forge or bypass the branded type, especially anywhere routing hints or citations are assembled.

• Supported vs related-material mode semantics
  The PR description explicitly says q15 is the residual wobble point. That makes the supported-mode path the judgment-heavy area: verify the new gold cases are actually protecting mode/citation behavior, not just answer phrasing.

• Gold additions q11–q15
  Since these are meant to red-team extraction demands and injection attempts, check that the canaries are corpus-specific leak tripwires and that the new expectAnswerPatterns field pins shape without overfitting exact wording.

Things I noticed

🟡 Yellow flags — consider for this PR or a follow-up:

• The review surface is dominated by demo/corpus/index.json, so the real merge risk is concentrated in unseen logic. I’d put extra scrutiny on version-rejection, public-safe field derivation, and mode-finalization tests.
• [UNVERIFIED] Since the PR closes related-material structurally but calls out supported-mode hint citations as the remaining edge, it would be worth confirming the new gold coverage actually fails if supported-mode prose starts synthesizing private implications from hint-only citations.

No visible red flags from the diff shown here.

Good patterns

• Sequencing the adversarial gold coverage before the structural changes is very aligned with the repo’s eval-first regression contract.
• Keeping the demo index migration mechanical, with hash/vector invariants called out, is a strong safety pattern for a boundary-sensitive schema bump.

Suggested improvements

1. If not already present, add a focused unit test proving related-material mode ignores any model-returned prose and always emits the fixed public-safe template.
2. Make the stale-index error message include both expected and found schema versions; that will help now that v2 indexes are intentionally invalid.
3. Add a narrow regression test showing private-note title cannot be assigned to any traveling metadata field without going through the public-safe lint path.

Surmado Code Review (v1.2-mt) is an automated review, designed to work alongside human judgment.

Want to change your STANDARDS.md or YML? Edit it directly, or tune it with our AI agent Scout.

Comment /rerun-review on this PR to refresh the review — costs 1 additional PR credit.

Responding to the automated review (a79fff2 addresses the actionable parts):

Suggestions. (1) A test proving plausible model prose is discarded in related-material mode already exists — answer: finalizeAnswer makes related-material prose deterministic in test/engine.test.ts feeds a confabulated summary of the private note through the real pipeline and asserts the canary phrase cannot survive. (2) The schema-mismatch error now names the found version alongside the expected one. (3) Added a keyless invariant test (demo/artifacts.test.ts): every committed demo entry's contentHash must equal the hash of today's embed-text derivation, which pins exactly the migration claim the JSON diff is too large to eyeball — the v2→v3 rewrite preserved the bytes the committed vectors were embedded from.

Questions. (1) Other construction paths for PublicSafe: one, and it's documented at the type (src/types.ts) and in NEXT-STEPS A1 — the JSON read path. readIndexFile casts stored entries back to IndexEntry, which launders the brand without re-linting; the guarantee is "linted when the corpus was built", backstopped by the v3 shape check in entryIsValid and the gold canaries at answer time. No runtime code mutates the fields after construction (toRoutingHint only copies them). (2) Supported-mode canaries: intentionally prompt/eval pressure, not structure — templating supported-mode prose would mean templating record-backed answers, which is the product. That residue is named in NEXT-STEPS A2 and owned by q15's canary patterns.

Generated by Claude Code